QRZ! Ham Radio 3/QRZ Ham Radio Callsign Database - Volume 3.iso/digests/tcp/930280.txt

Internet Message Format | 1994-06-04 | 23KB

Date: Fri, 29 Oct 93 04:30:02 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V93 #280
To: tcp-group-digest


TCP-Group Digest            Fri, 29 Oct 93       Volume 93 : Issue  280

Today's Topics:

                     AMPR and gatewaying (3 msgs)
                       Re- TCP broadcast storm
                             unsubscribe

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 29 Oct 93 00:19:57 EDT
From: Bob Ross <[e-mail]>
Subject:
To: tcp-group <[e-mail]>

unsubscribe

------------------------------

Date: Thu, 28 Oct 93 16:53:06 EDT
From: [e-mail] (D. Crompton)
Subject: AMPR and gatewaying
To: [e-mail], [e-mail]

I see a possible trend in gateways that is bothering me somewhat.
That is using a "wired/commercial" network to pass AMPR traffic
WHEN an existing AMPR circuit either exists or could easily be made
to exist.

Certainly there is no argument for many of the circuits - I.E.
Australia to the US etc. The problem is when you have two adjacent areas within
the US that use gatewaying when an AMPR radio cicuit exists. We are
Amateur Radio and RF is our "thing". Modulating it with digital data or
whatever. The more we depend on "wired" networks the less autonomous we
become.

I see this reasoning starting to set in here on the East coast. "Well
it's a whole lot less trouble to just gateway than setup an RF link, so
why bother. We have RF links that are a mess. Have we lost sight of what
this is all about?

I really think there should be a policy established on this. Amateur (RF)
circuits should be used whenever possible. If they do not work well or
we need to improve the RF protocol then lets go ahead and do it. Anyone
can send data down a wireline especially when the transport is being handled
by someone else. The last time I checked we were Amateur RADIO operators,
not Amateur network operators. I guess if every user had FREE internet
connections at their home they would be happy - hey then you would not
need the radio! Seems to be what everyone is pushing for anyway.

I am contemplating setting up a gateway. It will be my policy if and
when I do, to NOT pass traffic to areas which can be reached by RF. I
don't care how slow the circuit is. If engineering wise a circuit is
feasible via RF than that's the way it should go.

Perhaps some will think that is to strong an approach, but I think
that we really have to take a good look at this and try to see where
it is all going. I work with "wirelines" all day long and it is no
big thrill in my book to have data go half way around the world in
that manner, much the same as we take making a worldwide phone call
for granted. Send the same via radio though and it will excite the real
"RF freaks". Maybe technology has really gone beyond Amateur radio. It
won't be to many more years when you will have a palm size personal
communicator that will transceive in many modes to anywhere in the world
via satelite. Of course it will cost money, a dirty word for most hams.
Oh I guess that is why all this gatewaying has caught on - it is FREE. If
it cost money we would not be doing it. Which brings up a point - someone
IS paying for it. We are just on a free ride.

Fire away...

Doug

------------------------------

Date: Thu, 28 Oct 93 12:38:40 HST
From: Antonio Querubin <[e-mail]>
Subject: AMPR and gatewaying
To: [e-mail] (D. Crompton)

> I see a possible trend in gateways that is bothering me somewhat.
> That is using a "wired/commercial" network to pass AMPR traffic
> WHEN an existing AMPR circuit either exists or could easily be made
> to exist.

The situation is similar to the distribution of satellite gateways
around the world.  Some places have too many, some not enough.

> I really think there should be a policy established on this. Amateur (RF)
> circuits should be used whenever possible. If they do not work well or
> we need to improve the RF protocol then lets go ahead and do it. Anyone

Not sure if we need a set policy.  I'd rather let common sense take
over and have people in the same region cooperate to make maximum use
of the resources they have.  I've gotten a lot of initial contacts from
people thinking about setting up a gateway where there is one already
nearby.  I inform these people about the nearby gateway and it's their
choice as whether to pursue a new gateway, or help out with the
existing network surrounding the nearby gateway, or simply become end-nodes.

> can send data down a wireline especially when the transport is being handled
> by someone else. The last time I checked we were Amateur RADIO operators,
> not Amateur network operators. I guess if every user had FREE internet

We are amateur communication operators.  The media and modes of
communication that we use will continue to increase and evolve.
Consider communication via fiber optics for example.  This is still
communication via E&M waves.  The fiber is nothing more than a
dielectric waveguide.  The wavelength is measured in nanometers.
This is by no means a stagnant hobby.

> connections at their home they would be happy - hey then you would not
> need the radio! Seems to be what everyone is pushing for anyway.

True.  The way things are going the average Joe may get Internet
access by landline before the ham next door does by radio.

> I am contemplating setting up a gateway. It will be my policy if and
> when I do, to NOT pass traffic to areas which can be reached by RF. I
> don't care how slow the circuit is. If engineering wise a circuit is
> feasible via RF than that's the way it should go.

Well, Hawai`i IS reachable via 300 BAUD HF packet from the U.S.
mainland and Australia.  But I don't expect us to go back to that.
I'd rather wait for geostationary satellite routing.

> via satelite. Of course it will cost money, a dirty word for most hams.
> Oh I guess that is why all this gatewaying has caught on - it is FREE. If
> it cost money we would not be doing it. Which brings up a point - someone
> IS paying for it. We are just on a free ride.

May as well enjoy the ride while it lasts :-).

Tony

------------------------------

Date: Thu, 28 Oct 1993 23:38:00 -0600 (MDT)
From: William Ti Baggett <[e-mail]>
Subject: AMPR and gatewaying
To: "Dr. Osborne AA5ZQ" <[e-mail]>

On Thu, 28 Oct 1993, Antonio Querubin wrote:

> > I see a possible trend in gateways that is bothering me somewhat.
> > That is using a "wired/commercial" network to pass AMPR traffic
> > WHEN an existing AMPR circuit either exists or could easily be made
> > to exist.


I have thought about and discussed with others this topic for some time now,
but not really to any great extent. I agree that RF links should be used
whenever they exist, but from my (limited) experience in packet radio so
far, making RF links exists is not as easy as I thought. So here's my 2
cents worth.

>
> We are amateur communication operators.  The media and modes of
> communication that we use will continue to increase and evolve.
> Consider communication via fiber optics for example.  This is still
> communication via E&M waves.  The fiber is nothing more than a
> dielectric waveguide.  The wavelength is measured in nanometers.
> This is by no means a stagnant hobby.

This is where I start having an opinion. I agree with Tony here. There is
a lot more to communication than just antennas and transmitters, at least
from what I've gotten out of Ham Radio in the past 8 years. When we get to
the basics, its all E&M waves, but thats not the point I'm trying to make.

I'm an undergraduate Electrical Engineering student here at New Mexico
State University. I've found that amateur radio is a fascinating hobby
with a lot of different fields that one can enjoy and learn about. This
has inspired me to choose my major that I have.

I also happen to enjoy the digital communications end of amateur radio and
because of this I have set up the gateway on campus here (NMSUGW). From
this experience I have learned (and continue to learn) an INCREDIBLE
amount about computer networking with protocols and the different problems
that arise from it. I am by no means a digital communications guru like
several are who read these groups, but it is still applicable knowledge.
TCP/IP (at least to me) works the same over Ethernet and the radio - only
their physical data layers are different. Currently, I'm even running
several experiments to determine packet retry rates for different
protocols, and in the future may experiement around with different
modulation schemes.

THAT is what I think amateur radio is. It's not just radio anymore. It is
non-professionals (which I am) experiementing and developing new
methods of communications. Interfacing radio packets into different LANs
Via Internet is something that the gateway sysop's are developing and
experimenting with.


>
> > connections at their home they would be happy - hey then you would not
> > need the radio! Seems to be what everyone is pushing for anyway.
>
> True.  The way things are going the average Joe may get Internet
> access by landline before the ham next door does by radio.
>

Yeah, especially at 1200 bps which most probably 98% of hams are using (at
least around here). Also compare prices:
2nd phone line:     $30 installation / $16 a month
14.4Kbps V42bis modem:   $147

Heck I cant even get Digital Music Express from our cable company for that.
So, do you want Internet access or communication with other amateurs?
I prefer chatting with amateurs rather than the other students, etc on
IRC. But thats me. If you want Internet access, but a telephone modem and
get on the Internet somehow. If you want on packet, get a TNC and a good
radio modem.

The gateway here is intentionally set up NOT to allow amateurs access to
the Internet. We saw no reason why we should. We are only providing a
method to route amateur packets from southern NM to other parts of the
world. This depends on the gateway administrators.

This is also where the feasiblity of RF links come in: OPINION ALERT!
This digital communications stuff is TOO complicated for the average
packeteer!

I do not think that amateur radio as a whole is any longer on the leading
edge of technology. The communications graduate students here at NMSU have
some real INTERESTING digital communications projects. After seeing them
present their papers about interleaving, 8 PSK, 16 PSK, etc I wonder why
we're still at FSK. Maybe bandwidth has something to do with it. I'll
learn more as a graduate student myself. However, I don't think hams are
going to want to build their own RF radios to handle weird modulation
schemes. Yeah, the FCC may restrict the modulation schemes, but we can
get approval for experimentation. At 9600 bps, 19.2Kbps, or even 56Kbps
(which is getting pretty technical) I don't think amateur radio will ever
have a fully interconnected network. I hope that I'm wrong and I intend to
tinker with my own modems someday when college is not such a factor. I
think the hams should design their own stuff instead of having someone
else do it for them. Only difference with buying ready made equipment for
a 9600 bps network and the Internet is that the Internet is already in place.

I could continue by commenting about how hard it is to find protocol specs
for someone who wants to develope something, but I think I beat that horse
a few weeks ago.


> > I am contemplating setting up a gateway. It will be my policy if and
> > when I do, to NOT pass traffic to areas which can be reached by RF. I
> > don't care how slow the circuit is. If engineering wise a circuit is
> > feasible via RF than that's the way it should go.

Again, I do not think amateur radio operators are going to go to the
trouble of 'engineering' a network (at least most of them). Money, and
equipment seem to be factors in developeing a fully conencted network.

I agree with using common sense when it comes to routing from the
gateways. El Paso has NEVER had a packet connection with the rest of
Texas. It now has one. However, Each town does not need a gateway. The
gateways and the Internet can act as a 'super highway' backbone while
9600+ backbones can be implemented to get traffic from several LANS into
the gateway.

> > Oh I guess that is why all this gatewaying has caught on - it is FREE. If
> > it cost money we would not be doing it. Which brings up a point - someone
> > IS paying for it. We are just on a free ride.

Well, my tuition and taxes are providing the connection to Internet for
our radio club. If it disappeared tomarrow, I think I got a good education
out of setting up a gateway (I can even talk intelligently with the
networking folks on campus! Hmmm, wanna hire someone?)

BTW: NMSU networking was really interested in our project and how amateurs
run TCP/IP over RF. Unfortunatly they weren't impressed at the 500+ second
Round Trip Time to Albuquerque...

> > Flame On...

I dont consider my comments as flames (and I hope no one else does
either). These are just my personal opinions. Heck, I'm still young and
new to this. These are just my observances.

I hear some people already saying it: 'He wants to build something??!! I
bet he also likes CW!' Yep, I enjoy CW. Just wish school didnt take so
much time that my code speed has fallen from 20 wpm to 2 wpm ;-)

I'll step off my disillusioned soapbox now and do some homework...

73,
AA5DF, Tim

Disclaimer: As an undergraduate student I'm not allowed to hold an opinion
that in any way, shape, or form reflects that of NMSU.


********************************************************************
Tim Baggett, AA5DF                    Electrical Engineering Student
                                      New Mexico State University
Internet: [e-mail]
AMPR: [e-mail]           US Snail: 1970 Buchanan Avenue
Twisted Pair: [phone]                    Las Cruces, NM 88001
********************************************************************

------------------------------

Date: 27 Oct 1993 17:45:00 U
From: "MGauthier" <[e-mail]>
Subject: Re- TCP broadcast storm
To: [e-mail]

Subject:     Re: TCP broadcast storm
[To R. Braden:  there is a question (or observation) at the end of this
 message asking why RFC 1122 doesn't explicitly say that TCP should
 always ignore and never generate broadcast/multicast packets, instead
 of just mentioning SYN packets.]

|From: "Ray Abbitt" <[e-mail]>
|SUBJECT: Kind of interesting problem.
|
|>From: Glenn Davis <[e-mail]>
|>Subject: TCP broadcast storm
|>I am troubleshooting a particularly devilish network problem.  About two
|>days ago I started seeing very high TCP broadcast traffic on our internal
|>TCP/IP network.  After taking a network sniffer to the problem I discovered
|>packets like:
|>
|>13-OCT-1993 02:59:09.76 02-60-8C-A5-4F-BD FF-FF-FF-FF-FF-FF  08-00 len=  46
|>IP: vers=4 hdrlen= 5 lngwrds, svc:Routine
|>    total len=   40  ID=%X967E frag ofs=    0
|>    TTL= 30 prot=  6 TCP (Transmission Control), cksum=%X3B1E
|>    src=255.255.255.255  dest=255.255.255.255
|>TCP:port:src=31876 dest=132 seq#=523398 ack#=523398
|>    window=0 len=5 Lwrds,ACK,RST cksum=39AD urgentptr=0
|>FFFFFFFF 3B1E061E 0000967E 28000045 E..(~......;....  0000
|>86FC0700 86FC0700 8400847C FFFFFFFF ....|.....|...|.  0010
|>    4646 45434620 0000AD39 00001450 P...9Z.. FCEFF    0020
|>
|>Approximately 35 network stations (PC's running Netmanage TCP/IP) were
|>sending out these packets as fast as their network adapters would allow!
|>
|>What seemed to happen is: each station would see a packet like the one
|>above, and send out a RST (reset) response (ie this packet not for me).
|>This would repeat itself ad-nauseum, dragging the network down with all
|>the broadcast traffic!
|>[...]
|>The only thing that stopped the beast was to shut down the entire network!
|
|I ran this by one of the other guys at work and got this reply:
|
|FROM:  FRANK H. COLETTI([e-mail])
|Subject: Kind of interesting problem.
|Ray: This is a known bug in TCP traffic and was probably started by some-
|one who intentionally wanted this to happen. As far as I understand it
|you can start it by custom making an ARP packet, or some other such packet,
|and instead of putting your MAC address in the source field, you put the
|broadcast address. This causes other machines that get the packet via the
|broadcast to respond and automatically put in the original packet's
|source address-in this case, the broadcast address again. This causes
|a "Broadcast Storm" and what you saw is exactly what happens. It brings
|the network to its knees. In one of the classes I attended they said
|that some college guy did it on the Internet a couple of years ago and
|promptly brought the Internet down.
|[...]

I don't think this is a "known bug in TCP traffic", but rather a bug
in that particular TCP implementation (unless you mean that particular
bug is known to be present in a number of TCP implementations).
A TCP should NEVER reply to a RST packet.  Although it's a bit spread
out, this is rather clear from RFC 793 ("SEGMENT ARRIVES", pages 65-76),
and from this explicit paragraph on page 36:
    1.  If the connection does not exist (CLOSED) then a reset is sent
    in response to any incoming segment except another reset.  In
                                        ^^^^^^^^^^^^^^^^^^^^
    particular, SYNs addressed to a non-existent connection are rejected
    by this means.

Generally speaking, a proper TCP/IP implementation should NOT be prone
to broadcast storms.  There are many discussions in the RFCs on steps
that must be taken to avoid such possibilities.  If you find software
that generates broadcast storms, then most likely the software itself
is the culprit.  I know of no way for IP or TCP to be subject to broadcast
storms, **when properly implemented according the the latest RFCs**.
(Please correct me if you know full details of a valid counterexample.)
I don't claim that most implementations are fully conformant :-)

The above TCP/IP implementation has a second bug, the removal of which
would avoid this broadcast storm.  Simply said, IP packets with broadcast
or multicast source addresses MUST be discarded.

RFC 1122 says (for TCP and UDP):

         4.2.3.10  Remote Address Validation

            A TCP implementation MUST reject as an error a local OPEN
            call for an invalid remote IP address (e.g., a broadcast or
            multicast address).

            An incoming SYN with an invalid source address must be
            ignored either by TCP or by the IP layer (see Section
            3.2.1.3).

            A TCP implementation MUST silently discard an incoming SYN
            segment that is addressed to a broadcast or multicast
            address.

         4.1.3.6  Invalid Addresses

            A UDP datagram received with an invalid IP source address
            (e.g., a broadcast or multicast address) must be discarded
            by UDP or by the IP layer (see Section 3.2.1.3).

            When a host sends a UDP datagram, the source address MUST be
            (one of) the IP address(es) of the host.

It is clear from the above that broadcast and multicast addresses are
not allowed as source addresses in IP datagrams, and that such datagrams
should be discarded.  This is also stated explicitly in section 3.2.1.3
of RFC 1122, on IP addressing:

         3.2.1.3  Addressing: RFC-791 Section 3.2
            [...]
            When a host sends any datagram, the IP source address MUST
            be one of its own IP addresses (but not a broadcast or
            multicast address).

[I believe there is an exception to the above for IP-level IP address
 discovery protocols such as BOOTP, in which case 0.0.0.0 is used as
 a source address by the BOOTP client. -MEG]

            A host MUST silently discard an incoming datagram that is
            not destined for the host.  ...
            [...]
            A host MUST silently discard an incoming datagram containing
            an IP source address that is invalid by the rules of this
            section.  This validation could be done in either the IP
            layer or by each protocol in the transport layer.
            [...]


I propose that the stated TCP/IP implementation has yet a third bug,
removal of which would also prevent a broadcast storm.  It is simply that
TCP should never respond to broadcast or multicast packets.  TCP is not a
broadcast/multicast protocol, and should never generate (or respond to)
such traffic.  (I'm ignoring the ARP mechanisms, which operate at the
network level; ARP has / should have its own mechanisms to avoid
broadcast storms.)  However, I couldn't find any explicit statement of
this more general that what is found in section 4.2.3.10 of RFC 1122
(see above quote).  Why isn't this clearly pointed out in RFCs?
Looks like an omission...


So the solution to Glenn's problem (other than shutting down the net for
a short term fix) would be to contact the suppliers/writers of the
TCP/IP software and tell them how buggy their software is.  You could
quote the above.

73,

-Marc     VE2SOR
--
Marc E. Gauthier     Software Eng. Lab, IIT, National Research Council Canada
[e-mail]  Building M-50, Ottawa ON, Canada  K1A 0R6
[phone]   fax: [phone]   home: [phone]  (Hull QC)
NCFreeNet: [e-mail]     Disclaim: I speak for myself only

------------------------------

Date: Fri, 29 Oct 93 1:10:41 CDT
From: [e-mail]
Subject: unsubscribe
To: [e-mail]

unsubscribe

------------------------------

Date: Thu, 28 Oct 93 15:35:40 +0100
From: Alan Cox <[e-mail]>
To: [e-mail]

Several tcp/ip stacks respond with ACK's to out of sequence RST frames
and break all the rules. Nevertheless with the exception fo the current
Linux one (which I'm fixing) I know of none stupid enough to reply
to a frame with broadcast addresses.

ALan

------------------------------

End of TCP-Group Digest V93 #280
******************************
******************************